Как многие из вас знают, у компании VMware есть средство для резервного копирования виртуальных машин на серверах VMware ESXi - VMware vSphere Data Protection (VDP), входящее в состав платформы виртуализации VMware vSphere 5.1.
Это решение построено на базе продукта EMC Avamar, что позволяет производить резервное копирование содержимого гостевой ОС виртуальной машины, без агентов и со встроенной дедупликацией. Этот продукт заменил предыдущее решение vSphere Data Recovery, которым ранее бэкапились виртуальные машины.
По-сути, отличия заключаются в том, что VDP Advanced может применять дедупликацию на хранилищах до 8 ТБ, поддерживает резервное копирование до 400 ВМ и имеет в своем составе агентов для восстановления объектов ПО Microsoft. В частности, VDP Advanced может восстанавливать отдельные объекты Microsoft SQL (все приложение, файлы БД или только архивные логи) средствами SQL Agent, а Exchange Server Agent позволяет производить гранулярное восстановление почтовых ящиков и отдельных сообщений.
Продукт традиционно поставляется в виде виртуального модуля (Virtual Appliance) и требует обязательного наличия vCenter Server 5.1, а также установленного vSphere Web Client.
Ценовая политика на решение vSphere Data Protection Advanced вызывает недоумение: за сокет сервера ESXi придется заплатить $1095 (в ценах NAM). И это при том, что Veeam Backup and Replication 6.5 Enterprise, имеющий намного больше возможностей, стоит практически столько же.
Более подробно о решении VMware vSphere Data Protection Advancedможно почитать в официальном пресс-релизе.
Компания VMware традиционно выпустила черновик своего руководства по обеспечению информационной безопасности виртуальной инфраструктуры - VMware vSphere 5.1 Security Hardening Guide Draft. Традиционно - потому что, как правило, VMware делает доступным черновик руководства для его публичного обсуждения, а через пару-тройку месяцев выпускает его финальную версию. Так было и с прошлой версией - vSphere 5.0 Security Hardening.
Руководство, как обычно, состоит из экселевских табличек:
Пока в документе мало что добавилось нового с прошлой версии (например, в секции виртуальных машин - ничего вообще). Обещают, что в скором времени Security Hardening Guide будет включать в себя секции с руководствами по обеспечению безопасности компонентов Single Sign-On (SSO) и vCenter Server Virtual Appliance.
Если заглянуть в секцию Network утилиты esxtop, то там (начиная с ESXi 5.1) можно увидеть объекты Shadow of vmnic1 и т.п.:
На самом деле, эти штуки созданы для обеспечения работы функций VDS Network Health Check, которые появились в VMware vSphere 5.1. Для каждого физического интерфейса создается shadow port, через который посылаются пакеты Health Check, связанные с состоянием этого порта. Эти виртуальные интерфейсы можно мониторить на предмет работоспособности означенной функциональности.
Если эти штуки вам мешают, то можно убрать их, отключив модули хоста ESXi, связанные с хэлсчеком (заодно и в целях безопасности). Для этого нужно выполнить следующую последовательность команд для выгрузки ненужных модулей:
Помните, что после перезагрузки эти изменения не сохранятся - модули снова будут загружены автоматически.
Кстати, не по теме, но хозяйке на заметку: если вы видите, что в esxtop какой-либо счетчик принимает только значения 0 или 100 - знайте, что это просто означает работает эта штука в данный момент времени или нет. Так, например, происходит с SIOC. Просто нет еще в esxtop булевых метрик.
Как многие помнят, ранее в настройках VMware Tools можно было настраивать синхронизацию времени гостевой ОС со временем хост-сервера VMware ESXi. Доступно это было при двойном клике на иконку VMware Tools в гостевой системе:
Теперь же, начиная с vSphere 5.1, при двойном клике на иконку VMware Tools вы увидите следующее:
То есть тут, по-сути, доступна только информация о версии пакета. Это правильно, так как пользователю виртуальной машины не должно быть доступно никаких действий и настроек, относящихся к слою виртуализации.
Вместо этого, различные настройки, в том числе синхронизации времени, были вынесены в категорию VMware Tools опций виртуальной машины (Virtual Machine –> Edit Settings –> Options –> VMware Tools):
Теперь администраторам VMware vSphere не требуется полномочий в гостевой ОС, чтобы регулировать настройки VMware Tools.
VMware vCenter Support Assistant 5.1 - это бесплатный плагин к VMware vCenter Server, который призван облегчить сбор диагностических данных об инфраструктуре VMware vSphere, а также помочь обратиться в техническую поддержку:
Если вы обращались в техподдержку VMware, то, наверняка, знаете, что это не очень удобный и весьма замороченный процесс. Теперь все это станет проще, поэтому продукт просто необходимо поставить в своей инфраструктуре. Тем более, что это плагин к vCenter, а не виртуальный модуль (Virtual Appliance).
Интересные новости приходят от Дункана: в VMware vSphere 5.0 Update 2 при переименовании виртуальной машины во время миграции Storage vMotion ее VMDK-диски также переименовываются (раньше это не работало - менялось только имя машины). Но это, почему-то, не включено по умолчанию.
Чтобы это заработало нужно добавить расширенную настройку VMware vCenter. Для этого идем в "Administration" -> "vCenter Server Settings" -> "Advanced Settings" и добавляем параметр:
provisioning.relocate.enableRename со значением true
Итак, титаническая работа была проделана - и диски теперь переименовываются. Однако, почему эта настройка не активирована по умолчанию? Непонятно - бажит наверное...
Для VMware vSphere 5.1 эта штука пока не актуальна (только vSphere 5.0 Update 2), но обещают, что скоро она заработает с очередным апдейтом. Кстати, а почему тут только интерфейс добавления расширенных настроек и нет удаления?
Оказывается, один из самых частых вопросов по продукту для виртуализации настольных ПК VMware View - это как можно показать PCoIP-сессию пользователя через средство управления vSphere Client (по умолчанию там показывается чистый экран).
Для этого необходимо поменять настройку в шаблоне групповой политики (GPO) pcoip.adm. Находится этот шаблон на View Connection Server в папке:
Нужно запустить Group Policy Management, затем создать или привязать к организационной единице AD пула виртуальных ПК групповую политику. В контекстном меню данной групповой политики выбрать пункт "Edit…". В появившемся окне "Group Policy Management Editor" в контекстном меню пункта "Computer Configuration –> Policies –> Administrative Templates" выбрать пункт "Add/Remove Templates…". В появившемся окне "Add/Remove Templates" нажать на кнопку "Add.." и выбрать файл с ADM-шаблоном "pcoip.adm".
Далее нужно установить Enable для настройки "Enable access to PCoIP session from a vSphere console":
Затем нужно применить политики и презагрузить десктоп VMware View. После этого в vSphere Client в консоли виртуальной машины вы будете наблюдать то же самое, что и для VMware View Client:
Более подробно о настройках шаблона pcoip.adm можно узнать из документации.
Если вы попробуете импортировать виртуальную машину (или Virtual Appliance), которая была создана для настольных платформ виртуализации (например, VMware Workstation в формате 2gbsparse), в VMware vSphere 5.1 с помощью утилиты vmkfstools, то у вас это не выйдет. Вы получите подобное сообщение:
Failed to open 'VM-name.vmdk': The system cannot find the file specified (25).
Ошибка может быть и такой:
File [VMFS volume]\VM-name.vmdk was not found.
И такой:
Error Stack:
An error was received from the ESX host while powering on VM VM-name
Cannot open the disk '/vmfs/volumes/Datastore/VM-name/VM-name.vmdk' or one of the snapshot disks it depends on.
The system cannot find the file specified.
VMware ESX cannot find the virtual disk '/vmfs/volumes/Datastore/VM-name/VM-name.vmdk'. Verify the path is valid and try again.
Все это из-за одного и того же - в VMware vSphere 5.1 убрали автоматическую загрузку модуля multiextent, который и отвечает как раз за конверсию виртуальных дисков с hosted-платформ VMware в формат VMFS. Чтобы загрузить этот модуль нужно выполнить простую команду:
# vmkload_mod multiextent
Ну а чтобы выгрузить:
# vmkload_mod -u multiextent
Делать это можно смело, так как этот модуль отвечает только за работу с Non-VMFS дисками ВМ.
Так вот для тех из вас, кто решил встать на нелегкий путь сертификации VCAP (экзамены действительно сложные), вышло руководство VCAP5-DCA Study Guide, основанное на официальном Blueprint и насчитывающее 349 страниц (!). В нем, как это часто бывает, много ботвы, но и по существу есть немало полезного.
Для администраторов VMware vSphere в руководстве также найдется много интересного. Руководство снабжено картинками, командами CLI и, что самое нужное при подготовке к экзамену VCAP, отсылками к конкретным документам VMware (и их главам) по каждой теме. Штука местами очень классная - рекомендую.
Теперь, на основе статьи Франка, мы обобщим и актуализуем информацию по миграциям vMotion и Storage vMotion в разных контекстах - на уровне хранилищ, сети и хост-серверов VMware ESX.
Как и в прошлой статье, здесь будем пользоваться понятием стоимости миграции в единицах (cost) и максимального значения костов в тех же единицах (max cost), которое отображает предельно допустимое значение. Сумма костов операций vMotion и SVMotion не должна превышать max cost для соответствующего объекта (datastore, NIC и хост ESXi).
Теперь взглянем на таблички (в них есть не только vMotion, но и SVMotion):
Хост ESXi
Operation
Config Key
Cost
vMotion Cost
costPerVmotionESX41
1
Storage vMotion Cost
costPerSVmotionESX41
4
Maximum Cost
maxCostPerEsx41Host
8
Сеть
Operation
Config Key
Cost
vMotion Cost
networkCostPerVmotion
1
Storage vMotion Cost
networkCostPerSVmotion
0
Maximum Cost
maxCostPerNic
2
maxCostPer1GNic
4
maxCostPer10GNic
8
Хранилище (Datastore)
Operation
Config Key
Cost
vMotion Cost
CostPerEsx41Vmotion
1
Storage vMotion Cost
CostPerEsx41SVmotion
16
Maximum Cost
maxCostPerEsx41Ds
128
Читать эти таблички просто - например, для хоста ESXi стоимость миграции vMotion равна 1, а поскольку max cost равно 8, то всего на хост может быть 8 одновременных миграций в конфигурации по умолчанию. Либо допустимы одновременно: 1 миграция SVMotion (4 очка) и 4 штуки vMotion (по одному очку каждая), т.е. суммировать надо по костам: 4+1+1+1+1=8.
Для хранилища (Datastore) также есть ограничения vMotion, поскольку передаются страницы файла подкачки (если он не шаренный между хостами), а также производится передача владения VMX-файлом и другими файлами ВМ на хранилище. Но поскольку влияние это мало, то стоимость vMotion для хранилища всего 1 при максимальной емкости одновременных операций 128 (а вот SVMotion, требующая значительных ресурсов хранилища, "кушает" 16 единиц). Таким образом 1 операция vMotion съест 1 единицу коста, поэтому в этот момент для хранилища будет доступно только 7 миграций SVMotion, т.е. (128-1) div 16 = 7.
Соответственно, редактирование параметра Config Key для соответствующей операции позволяет изменять количество одновременных операций vMotion/SVMotion. Для редактирования параметра Config Key нужно отредактировать конфигурационный файл vpxd.cfg на сервере VMware vCenter, который находится в папке:
Если соответствующей секции нет, то ее можно просто добавить. Уменьшать максимальные косты точно можно, а увеличение работает не всегда. То есть гарантированно вы сможете только уменьшить число одновременных миграций vMotion или SVMotion, а вот увеличить - не факт. Ограничение можно делать двумя способами - повышением обычных костов или понижением максимальных костов.
Теперь самое интересное - это динамический параметр max cost для сетевых адаптеров. Как видно из таблицы, его действующее значение зависит от типа сетевого адаптера на хосте - 1G или 10G. Но, на самом деле, и не только от типа. Точнее - от скорости соединения для трафика vMotion между хостами ESXi, которую обнаруживает VMkernel. Таким образом:
Если VMkernel обнаруживает соединение на скорости 1Gbit/s - Maximum Cost выставляется в значение 4 (это верно и для случая соединения 1G<->10G).
Если VMkernel обнаруживает соединение на скорости 10Gbit/s - Maximum Cost выставляется в значение 8.
Если VMkernel обнаруживает соединение на скорости ниже 1Gbit/s - Maximum Cost выставляется в значение 2.
Таким образом, для адаптера возможны либо 2, либо 4, либо 8 одновременных миграций vMotion, в зависимости от действующей скорости соединения. Операция Storage vMotion, как видно из таблицы, костов сети не кушает.
Если ограничение для сети жестче (например, 4 миграции vMotion), чем ограничение для хоста (8 миграций vMotion) - то для машин этого хоста действует ограничение сети.
В рамках Phase V (они величают свои изыскания "фазами") был опубликован 80-страничный документ "Antivirus impact and best practices on VDI", в котором они сравнивают производительность различных антивирусных решений в инфраструктуре VDI (традиционно рассматривалась платформа VMware View / vSphere).
КДПВ из какого-то исследования (есть в документе):
Поэтому детально сравниваются только 3 антивируса для VDI:
Microsoft
Forefront Endpoint Protection 2010 (Now System Center Endpoint Protection 2012)
McAfee
- Enterprise 8.8.0
- MOVE Multiplatform AV 2.x
- MOVE Agentless AV 2.5
Symantec
- Endpoint Protection 12.1
Странно, что обошли стороной компанию Trend Micro с ее весьма популярным, заточеннымспециально под виртуализацию, решением Deep Security. Ну а нам было бы интересно посмотреть, как ведет себя Касперский в среде VDI. Но чего нет, того нет.
Конечно же, в документе рассмотрены и варианты развертывания, когда антивирусный агент работает за пределами виртуальных машин (за счет механизма VMsafe и EPSEC API):
В конце там много всяких графиков без окончательного вывода о том, что же все-таки лучше. Поэтому смотрите сами.
Начиная с версии VMware vSphere 4.0, компания VMware сделала замечательную вещь - все выпускаемые ей в комплекте с платформой виртуализации пакеты VMware Tools обратно совместимы со всеми прошлыми версиями хостов VMware ESXi:
Соответственно, на VMware ESX 4.0 можно использовать VMware Tools от vSphere 5.1, но как сделать это, не обновляя платформу виртуализации? Оказывается есть простой метод, опубликованный на v-front.de и основанный на информации из KB 2004018.
Там будет один или два файла с расширением .vib. Если их два, то тот, что с меньшим номером билда - это тулзы, содержащие только обновления безопасности, а тот, что с большим - включает и эти обновления, и багофиксы. Берем тот, что с большим номером (609), кликаем на нем 2 раза и проваливаемся дальше в архив, где виден репозиторий VMware Tools:
Эти три папки вы уже когда-то видели на Datastore в ESXi (во время установки тулзов). Создаем папку с именем vmware-tools на локальном хранилище ESX / ESXi и заливаем туда три извлеченные из vib'а папки, чтобы получилось вот так:
Теперь нужно настроить хост ESXi для использования данного репозитория VMware Tools. Для этого идем в Advanced Settings хоста ESXi и настраиваем параметр UserVars.ProductLockerLocation, где прописана версия тулзов в формате:
/locker/packages/<ESXi-Version> (ESXi-Version = 5.1.0, 5.0.0, 4.1.0 or 4.0.0)
В нашем случае она выглядит так:
/locker/packages/5.1.0
Меняем ее на путь к репозиторию: /vmfs/volumes/<имя Datastore>/vmware-tools.
После этого нужно перезагрузить хост, и изменения вступят в силу. Если перезагружать ESXi не хочется, то можно в корне файловой системы пересоздать символьную ссылку /productLocker:
Можно также вызвать команды, которые вызываются хостом для пересоздания символьных ссылок:
/sbin/configLocker - для ESX / ESXi 4.x
jumpstart --plugin=libconfigure-locker.so - для ESXi 5.x
Теперь остается только выбрать пункт Install/Upgrade VMware Tools в консоли vSphere Client при подключении к консоли ВМ для обновления компонентов пакета.
Многим интересующимся технологиями виртуализации известна компания Stratus Technologies, занимающаяся вопросами непрерывной доступности виртуальных машин (Fault Tolerance). Ранее продукты этой компании были доступны на платформе Citrix XenServer, где позволяли обеспечивать непрерывную доступность программными методами (продукт everRun от купленной компании Marathon):
Теперь у компании появился программно-аппаратный комплекс Stratus ftServer systems with vSphere 5.1, интегрированный с последней версией платформы виртуализации от VMware. Возможности решения из пресс-релиза:
Обещают аптайм на уровне 99.999%, что соответствует 5.26 минут простоя в год
Один или два 8-ядерных процессора Intel с поддержкой hyper-threading и архитектуры QuickPath
Полная поддержка SMP для построения архитектуры непрерывной доступности (vSMP?)
Встроенные интерфейсы 10Gb Ethernet
Проактивная система мониторинга, предупреждающая о возможных сбоях
Система обнаружения проблем в самом сервере и операционной системе, работающая без прерывания обслуживания виртуальных машин
Минимальный overhead (<5%) на систему виртуализации
Интеграция с VMware HA
Очевидно, что Stratus суетится накануне выхода программного vSMP Fault Tolerance от самой VMware.
Кстати в пресс-релизе по ftServer говорится о полугодовой гарантии на нулевой даунтайм в $50 000, покрывающей не только серверную часть, но и гипервизор (!). Так что торопитесь - возможно, парочка серверов от Stratus достанется вам совершенно бесплатно (учитывая тот набор багов, который мы видим в vSphere 5.1).
На днях компания VMware провела целых два тестирования (тут и тут), целью которых было сравнение производительности виртуальных дисков VMDK и RDM виртуальных машин на платформе VMware vSphere 5.1. Напомним про предыдущие сравнения VMFS и RDM, где основной моралью был тот факт, что оба этих типа виртуальных дисков практически идентичны по производительности, поэтому их следует использовать только в случаях, когда требуется специфическая функциональность (например, кластеры MSCS и большие диски для RDM):
Итак, для первого тестирования использовалась следующая конфигурация:
В качестве нагрузки использовался тест DVD Store для приложения, симулирующего интернет-магазин на платформе mySQL 5.5. Также было задействовано несколько тестовых клиентов для создания реальной нагрузки.
Масштабируемость производительности под нагрузкой (OPM - это orders per minute):
Как видно из результатов, масштабируемость производительности при увеличении числа ВМ почти линейная, а результаты различных типов дисков - идентичны (на самом деле, VMDK показал себя на 1 процент быстрее RDM для 1-й ВМ и чуть медленнее для 4-х ВМ):
Затраты ресурсов CPU на обслуживание операций ввода-вывода также чуть-чуть (на тот же 1%) лучше в пользу VMDK:
Теперь обратимся ко второму исследованию. Там использовалась следующая тестовая конфигурация, выдающая 1 миллион IOPS на тестах:
Hypervisor: vSphere 5.1
Server: HP DL380 Gen8
CPU: Two Intel Xeon E5-2690, HyperThreading disabled
Memory: 256GB
HBAs: Five QLogic QLE2562
Storage: One Violin Memory 6616 Flash Memory Array
VM: Windows Server 2008 R2, 8 vCPUs and 48GB.
Iometer Configuration: Random, 4KB I/O size with 16 workers
Тут уже измерялась производительность в IOPS для виртуальных машин на платформе VMware vSphere 5.1. При этом варьировался размер блока ввода-вывода (I/O Size) и сравнивались VMDK диски в VMFS5 и RDM-тома (нагрузка - случайное чтение):
Здесь уже на тот же самый 1% выигрывает RDM (для тестов на I/O). В тестах на MB/s ситуация в одном тесте оказалась в пользу VMFS. Масштабируемость тут уже показана не совсем линейная, при этом завал кривой начинается после размера блока в 4 Кб (единственный и по умолчанию в vSphere 5.1).
Второй тест - 60% операций чтения и 40% операций записи:
Такой рост производительности на блоке в 4 Кб объясняется просто - массив, примененный в тестировании, использует размер блока 4 Кб.
Вывод обоих тестов - виртуальные диски VMDK и RDM практически идентичны с точки зрения производительности.
Рост бизнеса компании ИТ-ГРАД по предоставлению в аренду виртуальных машин на платформе VMware vSphere в столице и, как следствие, рост числа сотрудников повлекли за собой необходимость поиска нового, более просторного помещения. Новый офис находится в бизнес-центр «Золотое кольцо», в минуте ходьбы от ст. м.Кожуховская. Телефон остался прежним: +7 (495) 748-05-77.
Точный адрес можно посмотреть в разделе "контакты". Мы всегда рады видеть Вас у нас в гостях! Также в связи с расширением у нас открыты вакансии в Москве.
Известный многим Duncan Epping в своем блоге рассказал об изменениях, которые произошли в механизме обнаружения события изоляции хост-сервера ESXi в VMware vSphere 5.1. Приведем их вкратце.
Как мы уже писали вот тут, кластер VMware HA следующим образом обрабатывает событие изоляции (отсутствие коммуникации с другими серверами кластера):
T+0 сек – обнаружение изоляции хоста (slave)
T+10 сек – хост slave переходит в режим выбора (“election state”)
T+25 сек – хост slave объявляет себя мастером (master)
T+25 сек – хост slave пингует адреса isolation addresses (по умолчанию один)
T+30 сек – хост slave объявляет себя изолированным и инициирует действие, указанное в isolation response
В VMware vSphere 5.1 появилось небольшое изменение, выражающееся в том, что хост ждет еще 30 секунд после объявления себя изолированным до инициации действия isolation response. Это время можно отрегулировать в следующей расширенной настройке кластера:
das.config.fdm.isolationPolicyDelaySec.
Таким образом, теперь последовательность выглядит так:
T+0 сек – обнаружение изоляции хоста (slave)
T+10 сек – хост slave переходит в режим выбора (“election state”)
T+25 сек – хост slave объявляет себя мастером (master)
T+25 сек – хост slave пингует адреса isolation addresses (по умолчанию один)
T+30 сек – хост slave объявляет себя изолированным и
T+60 сек - хост инициирует действие, указанное в isolation response
Наглядно:
Данные изменения были сделаны, чтобы обрабатывать сценарии, где не действие isolation response при наступлении изоляции хоста нужно обрабатывать через длительное время или не обрабатывать совсем.
Зачастую администраторам VMware vSphere требуется снять скриншот консоли виртуальной машины, который появляется вследствие различных ошибок или при установке ОС в ВМ. Делают они это, как правило, нажимая принтскрин в ОС, где установлен vSphere Client. Однако этот способ не очень красивый и не особо универсальный - ниже мы покажем, как правильно делать скриншот консоли ВМ.
Для этой операции мы снова задействуем MOB (Managed Object Browser), о котором мы уже писали тут и тут. Сначала нам надо получить MoRef ID виртуальной машины на определенном хосте VMware ESXi. Вкратце: MoRef ID присваивается виртуальной машине (и другим объектам) сервером vCenter для различных операций с ней, в том числе через MOB (он также используется в vCloud Director и других продуктах). MoRef ID уникален в пределах одного сервера vCenter.
Для получения MoRef ID воспользуйтесь статьей KB 1017126 - в ней все понятно расписано по шагам. Можно также воспользоваться скриптом vSphere MoRef ID Finder, который написал Вильям Лам.
Далее в адресной строке браузера наберите:
https://<IP хоста ESXi>/screen?id=vm-171
где vm-171 - это MoRef ID виртуальной машины. После авторизации пользователя (у которого должна быть привилегия VirtualMachine.Interact.ConsoleInteract) скриншот консоли ВМ будет выведен прямо в браузер.
При получении скриншота ВМ можно использовать еще несколько GET-параметров:
w = ширина получаемой картинки h = высота получаемой картинки x0 = координата X левого угла для снятия скриншота региона y0 = координата Y левого угла для снятия скриншота региона x1 = координата X правого угла для снятия скриншота региона y1 = координата Y правого угла для снятия скриншота региона
Примеры отработки MOB для получения скриншотов ВМ с различными параметрами:
Duncan и Frank, известные своими изысканиями в сфере механизмов отказоустойчивости (HA) и балансировки нагрузки (DRS) в виртуальной инфраструктуре VMware vSphere, опубликовали паруинтересныхматериалов, касающихся настройки среды vCloud Director и механизма Storage DRS.
Как вы знаете, в настройках кластера хранилищ (Datastore Cluster) есть галка, которая определяет, будут ли виртуальные диски VMDK машин обязательно находиться на одном хранилище (Datastore) при миграции средствами механизма Storage DRS:
Надо отметить, что галка Keep VMDKs together by default - это не совсем простая для понимания галка. Если ее не поставить, то действовать будет обратное - диски виртуальной машины будут обязательно размещаться на разных хранилищах. Это, по заверениям блоггеров, даст больше гибкости в использовании механизма SDRS в среде vCloud Director при перемещении виртуальных машин между хранилищами, что даст больше преимуществ в динамически балансирующейся среде (особенно для "тонких" дисков). Соответственно, по умолчанию галка Keep VMDKs together by default должна быть выключена.
В прошлом году я обещал выложить оффлайн-демо продуктов VMware, которые не попали в обзор, в случае, если будет запрос на их выкладывание сюда. Запросов оказалось достаточно, поэтому продолжим эту традицию, но уже без обзора, а просто выложим файлы списком.
Соответственно, нужно начинать отучать пользователей ходить через vSphere Client и приучать использовать веб. Проблема в том, что штатного способа сделать это нет. Если у пользователя есть доступ - то и клиент он всегда сможет скачать и использовать.
Поэтому William Lam придумал простой способ борьбы с этим. Надо открыть файл version.txt на сервере vCenter, который находится вот тут:
Дальше в значение версии клиента (exactVersion) нужно вписать несуществующую версию, например, 9.0.0. После этого, при логине через vSphere Client, пользователям будет предложено скачать версию клиента, которой не существует, что приведет к зацикливанию процесса:
Однако это приведет к желаемому результату - через vSphere Client пользователи не смогут залогиниться.
На сервере VMware ESXi это тоже можно применить, однако там нужно поправить файл clients.xml, размещенный по адресу:
/usr/lib/vmware/hostd/docroot/client
Так что пора уже переводить своих пользователей на браузер.
Таги: VMware, vSphere, Web Client, Обучение, ESXi, vCenter
Некоторые из вас знают, что компания VMware выпускает специализированный фреймворк VDDK (VMware Virtual Disk Development Kit), который позволяет просто обращаться с виртуальными машинами в контексте резервного копирования. Его используют практически все вендоры решений для РК виртуальных машин на платформе vSphere, например, Veeam Backup and Replication и Symantec BackupExec.
Не так давно было заявлено о том, что версия VDDK 5.1 может вызывать проблемы при использовании с VMware vSphere 5.1, что выражается в зависании и прерывании некоторых вызовов к функциям резервного копирования и восстановления (например, функции VixDiskLib_ConnectEx и VixDiskLib_Cleanup). Это описано в статье "Third-party backup software using VDDK 5.1 may encounter backup/restore failures", при этом проблема на сегодняшний день не имеет решения.
Так почему же пользователи продукта Veeam Backup and Replication этого не замечают? Все очень просто. Если прочитать статью "Symantec admits all its VMware backup customers are in danger", то становится понятным, что поскольку тестеры и разработчики Veeam давно работают с фреймворком VDDK (еще со времен VADP), то они уже успели понять, что это временами весьма глючная штука. Поэтому процессы Veeam Backup and Replication постоянно следят за работой служб VDDK, проверяют, не зависли ли они сами или их потоки, а в случае зависания (которое определяется грамотно выставленными таймаутами) - терминируют их безопасно для задачи РК. Мало того, в данный момент Veeam работает совместно с VMware над устранением данной проблемы.
Ну а как следует из названия упомянутой статьи, такой защиты у продуктов Symantec нет, поэтому пользователи Symantec BackupExec могут быть подвержены опасности зависания задач, а что еще хуже - проблеме неконсистентных бэкапов.
Для начала обратите внимание, что обновление вышло не для ESXi 5.1 (последней версии гипервизора), а для ESXi 5.0 - его предыдущей версии. Так что это обновление актуально только для тех, кто еще не успел переехать со старой версии платформы.
Помимо VMware ESXi 5.0 Update 2, вышел и VMware vCenter 5.0 Update 2. Новые возможности обновлений:
Официальная поддержка работы vCenter 5.0 на Windows Server 2012.
Официальная поддержка новых гостевых ОС: Oracle Solaris 11, Solaris 11.1, а также Mac OS X Server Lion 10.7.5.
Поддержка сервером vCenter механизма Guest Operating System Customization для следующих гостевых ОС: Windows 8, Windows Server 2012, Ubuntu 12.04, RHEL 6.2, RHEL 6.3.
На прошлой неделе мы писали про возможность бесплатного демо-доступа к работающей инфраструктуре VMware vSphere и средств vCloud Director от компании ИТ-ГРАД (даже регистрироваться не нужно).
Если вы не хотите сами устанавливать, настраивать и обслуживать операционную систему и необходимый Вам пакет программ, или, например, хотите показать клиенту демо-версию программы, но не знаете насколько он правильно сможет ее установить и настроить, то можно использовать уже готовые виртуальные модули (Virtual Appliances).
Технология VMware Virtual Appliances предоставляет возможность оперировать не набором операционных систем, программ и списком настроек под определенные задачи, а одним дистрибутивом, который представляет собой единое целое и позволяет решить конкретный набор проблем. Такой подход упрощает обслуживание и позволяет снизить затраты на дополнительный обслуживающий персонал. Теперь достаточно протестировать обновление, версию программы или операционной системы на одной машине и распространить дистрибутив на все остальные.
Виртуальные устройства – это операционная система и приложениея, объединенные с метаданными в стандартном формате OVF (Open Virtual Machine Format) . Даное устройство представляет из себя готовую для запуска виртуальную машину, что очень удобно для пользователя облачной инфраструктуры.
Не хотите создавать дистрибутив самостоятельно? Есть варианты!
В vSphere Web Client эти типы трафика можно просто назначить интерфейсу vmk (VMkernel):
Но можно ли управлять этими настройками с помощью интерфейса ESXCLI? Оказывается, что, начиная с версии vSphere 5.1, это делается очень просто. Интерфейс vmk можно "тэгировать" различными типами трафика, что означает, что он будет их пропускать. В командной строки ESXCLI администратору доступно множество команд tag в следующем пространстве имен:
esxcli network ip interface
Как и с многими другими объектами, с тэгами можно совершать операции get, add и remove:
vi-admin@vMA51:~> esxcli –server vcenter51 –vihost pod23-esx-01a.pml.local –username root network ip interface tag
Usage: esxcli network ip interface tag {cmd} [cmd options]
Available Commands:
add Adds a tag on a given VMkernel network interface.
get Gets the tags set on the given VMkernel network interface.
remove Removes a tag on a given VMkernel network interface.
Одновременно с этим компания StarWind объявила также о том, что решение StarWind iSCSI SAN 6.0 для хранения виртуальных машин VMware vSphere также становится бесплатным (при использовании дисковых ресурсов до 128 ГБ), при этом доступны все возможности продукта для обеспечения отказоустойчивости хранилищ. Об этом подробно написано в документе "StarWind iSCSI SAN Free. The difference between free and paid editions".
Для тех, кому лень открывать документ на английском, приводим обновленное сравнение бесплатного и коммерческого изданий StarWind iSCSI SAN 6.0:
StarWind iSCSI SAN
Free Edition - бесплатно
Коммерческие издания (в зависимости от лицензируемой емкости 1 ТБ - 512 ТБ)
Компоненты продукта
Лицензируемая емкость хранилищ
Не ограничена для одного узла и ограничение 128 ГБ для HA-конфигурации (на узел)
1 ТБ - 512 ТБ
Размер кэша
512 МБ
Не ограничен
Централизованное управление
StarWind Console
StarWind Console
Число серверов, входящее в лицензию
2
2 или 3
Число одновременных соединений по iSCSI к хранилищам
Как вы знаете, в VMware vSphere можно получить информацию о текущих лицензиях для хостов ESXi и vCenter как через "толстый" vSphere Client, так и через "тонкий" vSphere Web Client:
Иногда эту информацию хочется получить через API, например, чтобы иметь всегда актуальный отчет о лицензировании или в целях инвентаризации ключей. Для этого в иерархии объектов vSphere есть объект LicenseManager, который имеет методы для добавления, удаления и просмотра лицензий на хостах VMware vCenter / ESXi.
Для просмотра всех доступных лицензий в системе используется свойство licenses, которое содержит весьма подробную информацию о лицензиях, включая, собственно, сами лицензионные ключи и лицензированные фичи. Есть также свойства expirationDate, expirationMinutes и expirationHours, позволяющие узнать, когда лицензии закончатся.
Известный многим William Lam написал скрипт getLicenseInfo.pl, который использует LicenseManager для получения нужной информации о лицензировании (туда включена также информация не только о vSphere, но и о других продуктах семейства vCenter):
Скрипт может быть использован как для отдельных хостов ESXi, так и для централизованного сбора ключей через vCenter. Для отображения лицензионных ключей открытым текстом нужно вызывать скрипт с параметром –hide_keyfalse.
Кроме того, не так давно были воплощены в жизнь такие полезные службы vSphere для работы с SSD-накопителями, как SSD Monitoring (реализуется демоном smartd) и Swap to SSD (использование локальных дисков для файлов подкачки виртуальных машин). Однако функции кэширования на SSD реализованы пока совсем в базовом варианте, поэтому сегодня вам будет интересно узнать о новой технологии Virtual Flash (vFlash) для SSD-накопителей в VMware vSphere, которая была анонсирована совсем недавно.
Эта технология, находящаяся в стадии Tech Preview, направлена на дальнейшую интеграцию SSD-накопителей и других flash-устройств в инфраструктуру хранения VMware vSphere. Прежде всего, vFlash - это средство, позволяющее объединить SSD-ресурсы хост-серверов VMware ESXi в единый пул, используемый для задач кэширования, чтобы повысить быстродействие виртуальных машин. vFlash - это фреймворк, позволяющий сторонним вендорам SSD-накопителей и кэш-устройств использовать собственные алгоритмы для создания модулей обработки кэшей виртуальных машин (плагины vFlash Cache Modules). Будет реализован и собственный базовый алгоритм VMware для работы с кэшем.
Основная мысль VMware - предоставить партнерам некий API для их flash-устройств, за счет которого виртуальные машины будут "умно" использовать алгоритмы кэширования. Для этого можно будет использовать 2 подхода к кэшированию: VM-aware caching и VM-transparent caching:
VM-aware Caching (vFlash Memory)
В этом режиме обработки кэширования флэш-ресурс доступен напрямую для виртуальной машины, которая может использовать его на уровне блоков. В этом случае на уровне виртуального аппаратного обеспечения у виртуальной машины есть ресурс vFlash Memory определенного объема, который она может использовать как обычный диск в гостевой ОС. То есть, приложение или операционная система должны сами думать, как этот высокопроизводительный ресурс использовать. Можно вообще использовать его не как кэш, а как обычный диск, хотя идея, конечно же, не в этом.
VM-transparent Caching (vFlash Cache)
В этом случае виртуальная машина и ее гостевая ОС не знают, что на пути команд ввода-вывода находится прослойка в виде flash-устройств, оптимизирующих производительность за счет кэширования. В этом случае задача специализированного ПО (в том числе от партнеров) - предоставить оптимальный алгоритм кэширования. В этом случае будет доступна настройка следующих параметров кэша:
Гарантированный объем (Reservation size)
Выбор программного модуля-обработчика (vFlash Cache Module)
Размер блока (настраивается в зависимости от гостевой ОС)
Что делать с кэшем при перемещении виртуальной машины посредством vMotion (перенести вместе с ней или удалить)
При vMotion сервер vCenter будет проверять наличие необходимых ресурсов кэширования для виртуальной машины на целевом хосте ESXi. Для совместимости с технологией VMware HA, виртуальная машина должна будет иметь доступные vFlash-ресурсы на хранилищах хостов в случае сбоя (соответственно, потребуется эти ресурсы гарантировать).
В целом vFlash в VMware vSphere обещает быть очень перспективной технологией, что особенно актуально на волне роста потребления SSD-накопителей, постепенно дешевеющих и входящих в повсеместное употребление.
Давно мы что-то не писали про сравнения платформ виртуализации, которые, зачастую, сильно попахивают предвзятостью и переворачиванием фактов. Но на этот раз мы бы хотели отметить одно из немногих достаточно независимых сравнений "Enterprise Hypervisor Comparison", в котором автор сам явно указывает, что идеального продукта для любой инфраструктуры нет. Особенно если брать в расчет стоимость решения.
В документе рассмотрены следующие платформы виртуализации в различных аспектах функциональности, необходимой для среднего и крупного предприятия:
VMware vSphere 5.1
Microsoft Windows/Hyper-V Server 2012
Red Hat Enterprise Virtualization 3.1 (на данный момент в стадии беты)
Для Windows Server 2012 и Hyper-V данные приведены с учетом Microsoft System Center 2012
Service Pack 1, который еще не выпущен, о чем в документе сделана специальная пометка. Надо отметить, что автор рассматривал только полнофункциональные версии продуктов и не рассматривал их бесплатные версии.
В целом, получилось неплохое сравнение, которое, однако, нельзя рассматривать как единственный источник информации при выборе решения.
Таги: VMware, Microsoft, Red Hat, Сравнение, vSphere, RHEV, Hyper-V, Blogs, Enterprise
RSS
(128 ГБ)
